feat(venv): make wheel scripts runnable in venv#3743
feat(venv): make wheel scripts runnable in venv#3743rickeylev wants to merge 85 commits intobazel-contrib:mainfrom
Conversation
ref https://packaging.python.org/en/latest/specifications/binary-distribution-format/#installing-a-wheel-distribution-1-0-py32-none-any-whl for generic data scheme: these are usually installed to the venv root, but that seems ill-advised. So we install into a data sub-directory of the venv.
…into whl.with.data
Uses os.name to correctly assert the Scripts/ and Include/ directory paths when creating the virtual environment on Windows.
Also add debug info to venvs_site_packages_libs_test to help diagnose Windows CI failures.
…addition These changes seemed to cause many regressions in WORKSPACE mode in CI.
Also revert redundant bazel_skylib additions to example WORKSPACE files.
The original target was intended to be internal-only, so it has been renamed and all references updated. No alias was added as per instructions.
…d because data files are always added
…-platform support
aignas
left a comment
aignas
left a comment
There was a problem hiding this comment.
This is really good, thank you very much!
| mrctx.rename(src, dest) | ||
| return | ||
|
|
||
| # Fallback for Bazel < 8.0 |
There was a problem hiding this comment.
With this, we may remove the wheel.py file because we have the right fallbacks.
There was a problem hiding this comment.
I think we'd need this regardless? The starlark extract logic still has to look through the bin/ directory and and move files to rewrite-bin
There was a problem hiding this comment.
Well as far as what the wheel.py is doing, we have reimplemented everything in starlark a while ago. The only reason why we still needed to have something like the wheel.py is to install sdists, or use pip. The extraction logic can be done fully in starlark.
…s_python into venv.bin.runnable
Ah, I think I get what you mean. Do you want to file an issue for further discussion? entrypoints/scripts/things-in-bin seem distinct enough they warrant something in a provider, but it's not clear to me how a consumer can make effective use of it via a py_binary. |
…s_python into venv.bin.runnable
|
I got everything working except pythonw scripts under bazel 7. The root cause for this is wheel.py. We've hard-coded it to use a unix install format, so it rewrites #!pythonw to #!python. Later, when the rewrite tool goes to fixup the command line, it doesn't see pythonw, so can't generate the correct pythonw.exe part. Since we're going to remove wheel.py, I've just skipped that particular test. |
…into venv.bin.runnable
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
2 participants
Currently,
#!pythonbased scripts in a wheel are put into the venvas-is, so aren't actually runnable. Additionally, wheel entry points
aren't installed into the venv.
To fix, rewrite the scripts to re-exec themselves with the
python3binary in the same directory.
Also adds support for wheel entry points in venvs. This is done by
having the repo-phase parse entry_points.txt and defining a target for
each entry point. These targets run during build phase, so are able
to generate platform-specific outputs.
Cross-building with Windows is also added, supporting both Windows
as a target or exec platform to generate outputs for the target
platform.
Fixes #3202